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METHODOLOGY FOR DISCOVERING EXTENDED CAPABILITIES 
OF DEVICES IN AN ELECTRONIC NETWORK 

CROSS-REFERENCE TO RELATED APPLICATIONS 

5 

This application relates to co-pending U.S. Patent Application No. 
09/259,504, entitled "System And Method For Incrementally Updating 
Remote Element Lists In An Electronic Network," filed on February 26, 1999, 
to co-pending U.S. Patent Application No. 09/257,344, entitled "System And 

10 Method For Implementing Active Registries In An Electronic Network," filed 
on February 25, 1999, and to co-pending U.S. Patent Application No. 
09/289,500, entitled "System And Method For Maintaining Fully-Replicated 
Registries In An Electronic Network," filed on April 9, 1999, which are hereby 
incorporated by reference. The foregoing cross-referenced applications are 

15 commonly assigned. 

BACKGROUND OF THE INVENTION 
1. Field of the Invention 

20 

This invention relates generally to electronic networks, and relates 
more particularly to a methodology for discovering extended capabilities of 
devices in an electronic network. 

25 2. Description of the Background Art 

Implementing an effective method for utilizing extended capabilities of 
electronic devices within an electronic network is a significant consideration 
for manufacturers and designers of contemporary electronic systems. An 
30 electronic device in a distributed electronic network may advantageously 
communicate with other remote electronic devices in the network to share 
and substantially increase the resources available to individual devices in the 
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network. For example, an electronic network may be implemented in a user's 
home to enable flexible and beneficial sharing of resources between various 
consumer electronic devices, such as personal computers, digital video disk 
devices, digital set-top boxes for digital broadcasting, television sets, and 
5 audio playback systems. 

Managing and controlling a network of electronic devices may create 
substantial challenges for designers of electronic networks. For example, 
enhanced demands for increased functionality and performance may require 
more system processing power and require additional hardware resources 

10 across the network. An increase in processing or hardware requirements 
may also result in a corresponding detrimental economic impact due to 
increased production costs and operational inefficiencies. Furthermore, 
efficiently accessing the increased functionality may pose certain problems. 

Network size is also a factor that affects the control and management of 

15 an electronic network. Communications in an electronic network typically 
become more complex as the number of individual devices or nodes 
increases. Assume that a particular device on an electronic network is 
defined as a local device with local software elements, and other devices .on 
the electronic network are defined as remote devices with remote software 

20 elements. Accordingly, a local software module on the local device may need 
to communicate with various remote software elements on remote devices 
across the electronic network. However, successfully managing a substantial 
number of electronic devices across a single network may provide significant 
benefits to a system user. 

25 Furthermore, enhanced device capability to perform various advanced 

functions may provide additional benefits to a system user, but may also 
place increased demands on the control and management of the various 
devices in the electronic network. For example, an enhanced electronic 
network that effectively accesses, processes, and displays digital television 

30 programming may benefit from efficient network management techniques 
because of the large amount and complexity of the digital data involved. 
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In addition, the presence of electronic devices with extended 
capabilities and functionality may present a need for creating efficient 
techniques to allow discovery of the extended capabilities by various software 
elements in the network. For example, if an enhanced video cassette recorder 
(VCR) with extended capabilities is added to the network, then the other 
software elements in the network may require information about the 
existence and capabilities of the newly-added VCR, so that all software 
elements in the network may advantageously utilize the extended capabilities 
of the newly- added software device. 

Therefore, for all the foregoing reasons, implementing an efficient 
method for utilizing extended capabilities of electronic devices in a distributed 
electronic network remains a significant consideration for designers, 
manufacturers, and users of electronic systems. 
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SUMMARY OF THE INVENTION 

In accordance with the present invention, a methodology is disclosed 
for discovering extended capabilities of devices in an electronic network. In 
5 one embodiment of the invention, initially, a DCM manager (416) preferably 
performs a device discovery process for devices that are added to the 
electronic network by querying various relevant configuration information 
that is preferably stored in self-describing data of the added devices. In 
accordance with the present invention, the DCM manager (416) may discover 

10 relevant extended capability information for the added devices during the 
foregoing device discovery process. 

The DCM manager (416) then preferably instantiates a new device 
control module (DCM) for controlling an added device on the electronic 
network. The DCM manager (416) also preferably creates a DCM registration 

15 to register the new DCM into a local registry. The DCM registration may 

advantageously include one or more extended API attributes (EAAs) that each 
correspond to different extended capabilities of an added device on the 
electronic network. 

Subsequently, in accordance with the present invention, whenever a 

20 software module (such as an application program) requires a particular 
extended API to access a given extended capability of a target device, the 
software module may then propagate a query to the local registry for locating 
the appropriate DCM registration that corresponds to the target device. In 
some embodiments, the registry may similarly broadcast the query to other 

25 remote registries across the electronic network in the event that the initial 
query to the local registry is unsuccessful. 

If the foregoing query successfully locates an appropriate DCM 
registration, then the registry returns a corresponding DCM software element 
identifier to the software module that originated the query process. The 

30 software module may then access and scan a DCM attribute list from the 
DCM registration to locate an appropriate extended API attribute (EAA), in 
accordance with the present invention. 
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The software module may then preferably access and parse the 
extended API attribute to identify the corresponding extended API. Finally, 
the software module may responsively build a request call using relevant 
information from the extended API attribute, and may then send the request 
5 call to the target device's DCM through the extended API using any 
appropriate and compatible messaging protocol. 

The foregoing embodiment is discussed in the context of a single local 
software module discovering a single extended API, however the present 
invention may readily be utilized to allow any number of software modules 
10 across the electronic network to discover and utilize any number of local or 
remote extended APIs on various devices across the network. The present 
invention thus effectively facilitates discovery of extended capabilities of 
devices across the electronic network. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram for one embodiment of an electronic network, 
in accordance with the present invention; 

5 

FIG. 2 is a block diagram for one embodiment of an exemplary device 
from FIG. 1, in accordance with the present invention; 

FIG. 3 is a diagram for one embodiment of the memory of FIG. 2, in 
10 accordance with the present invention; 

FIG. 4 is a diagram for one embodiment of the network software of FIG. 
3, in accordance with the present invention; 

15 FIG. 5 is a diagram for one embodiment of the registry of FIG. 4, in 

accordance with the present invention; 

FIG. 6 is a diagram for one embodiment of the DCM attribute list of 
FIG. 5, in accordance with the present invention; 

20 

FIG. 7 is a diagram for one embodiment of the extended API attributes 
of FIG. 6, in accordance with the present invention; 

FIG. 8 is a diagram for one embodiment of an exemplary extended API 
25 attribute from FIG. 7 y in accordance with the present invention; 

FIG. 9 is a diagram for one embodiment of an exemplary method 
signature from FIG. 7, in accordance with the present invention; 

30 
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FIG. 10 is a flowchart of method steps for registering a DCM of an 
added device, in accordance with one embodiment of the present invention; 
and 

FIG. 1 1 is a flowchart of method steps for discovering extended APIs to 
access extended capabilities of a device, in accordance with one embodiment 
of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 



The present invention relates to an improvement in electronic network 
technology. The following description is presented to enable one of ordinary 
5 skill in the art to make and use the invention and is provided in the context 
of a patent application and its requirements. Various modifications to the 
preferred embodiment will be readily apparent to those skilled in the art and 
the generic principles herein may be applied to other embodiments. Thus, 
the present invention is not intended to be limited to the embodiment shown, 

10 but is to be accorded the widest scope consistent with the principles and 
features described herein. 

The present invention comprises a methodology for discovering 
extended capabilities of devices in an electronic network, and preferably 
includes a registry that is configured to include one or more extended 

15 attributes that each correspond to a different extended capability of a device 
on the electronic network. A software module, such as .an application 
program, may then advantageously access a particular extended attribute to 
thereby discover an appropriate extended application program interface for 
effectively communicating with the extended capability of the device on the 

20 electronic network. 

Referring now to FIG. 1, a block diagram for one embodiment of an 
electronic network 1 10 is shown, in accordance with the present invention. 
In the FIG. 1 embodiment, network 110 includes, but is not limited to, device 

25 A 1 12(a), device B 1 12(b), device C 1 12(c), and device D 1 12(d). In other 
embodiments, network 110 may readily be implemented using a larger or 
smaller number of devices than the four devices (device A 1 12(a) through 
device D 112(d)) shown in the FIG. 1 embodiment. 

In the FIG. 1 network 110, device A 112(a), device B 112(b), device C 

30 112(c), and device D 1 12(d) preferably communicate with each other through 
a commonly-shared network bus 120. In the FIG. 1 embodiment, network 
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bus 120 is preferably implemented according to the IEEE 1394 
interconnectivity standard. However, in alternate embodiments, other 
appropriate and compatible interconnectivity standards are also 
contemplated for use in conjunction with the present invention. 
5 In the FIG. 1 embodiment, network 110 may preferably be configured 

to operate in accordance with the Home Audio/ Video Interoperability (HAVi) 
core specification (version 1.0 beta, at www.HAVi.org) which is hereby 
incorporated by reference. Therefore, device A 1 12(a), device B 1 12(b), device 
C 1 12(c), and device D 1 12(d) may be implemented as various types of 

10 consumer electronics devices, including, but not limited to, personal 

computers, digital video disk devices, television sets, audio reproduction 
systems, video tape recorders (VCRs), and set- top boxes for digital video 
broadcasting. However, in various alternate embodiments, network 110 may 
readily be implemented as any appropriate electronic network configured to 

15 permit communication between any desired types of electronic devices. 

In the FIG. 1 embodiment, the various electronic devices that form part 
of network 110 preferably include the following four categories of electronic 
devices: full devices (FD), intermediate devices (ID), base devices (BD), and 
legacy devices (LD). The foregoing four categories of electronic devices (FD, 

20 ID, BD, and LD) are further discussed below in conjunction with FIGS. 2 and 
3. In alternate embodiments of the present invention, network 110 may 
readily include various other categories of electronic devices in addition to, or 
instead of, the four categories of FD, ID, BD, and LD. 

25 Referring now to FIG. 2, a block diagram for one embodiment of an 

exemplary device 112 from FIG. 1 is shown, in accordance with the present 
invention. In the FIG. 2 embodiment, device 112 preferably includes, but is 
not limited to, a processor 212, an input/output interface (I/O) 214, and a 
memory 216 that are each coupled to, and communicate with each other via, 

30 a common device bus 218. In the FIG. 2 embodiment, device 1 12 is 

preferably configured to represent either a full device or an intermediate 
device, as referred to above in the discussion of the FIG. 1 network 110. 
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In the FIG. 2 embodiment, processor 212 may be implemented to 
include any appropriate and compatible generic, multi-purpose 
microprocessor device. The FIG. 2 input/output interface (I/O) 214 
preferably provides an effective interface to facilitate communications 
between device 112 and network bus 120 (FIG. 1). In the FIG. 2 embodiment, 
memory 216 may be implemented to include any combination of desired 
storage devices, including, but not limited to, read-only memory (ROM), 
random-access memory (RAM), and various types of non-volatile memory, 
such as floppy disks or hard disks. The contents and functionality of 
memory 216 are further discussed below in conjunction with FIGS. 3 and 4. 

In accordance with the present invention, the FIG. 2 device 112 may 
include extended capabilities and functionality not typically found in similar 
devices. For example, in one embodiment, device 112 may be implemented 
as a video cassette recorder (VCR) that includes a non-standard half- speed 
fast forward capability. 

Referring now to FIG. 3, a diagram for one embodiment of FIG. 2 
memory 216 is shown, in accordance with the present invention. In the FIG. 
3 embodiment, memory 216 includes one or more device applications 312, a 
network application program interface (API) 314, network software 316, self- 
describing data (SDD) 320, a device driver 318, a platform- specific 
application program interface (API) 322, a vendor-specific platform 324, and 
one or more extended application program interface(s) (extended APIs) 326. 
In alternate embodiments, memory 216 may readily include various 
components and elements that are different from, or in addition to, those 
software components 312 through 324 discussed in conjunction with the 
FIG. 3 embodiment. 

In the FIG. 3 embodiment, device application 312 preferably includes 
software instructions that are executed by processor 212 (FIG. 2) to effectively 
manage and control the functionality of device 1 12. Network API 314 
preferably serves as an interface between various elements of network 
software 316 and device application 312. 
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In the FIG. 3 embodiment, network software 316 preferably includes 
one or more software elements that are executed by processor 212 to 
advantageously permit device 1 12 to communicate and cooperate with other 
devices in network 110. The contents and functionality of network software 
5 316 are further discussed below in conjunction with FIG. 4. 

Self-describing data (SDD) 320 preferably includes various types of 
relevant information regarding device 112. For example, SDD 320 may 
include information specifying the manufacturer, model, version, serial 
number, and other fixed data that specifically corresponds to device 112. 

10 Device driver 318 preferably includes appropriate software instructions that 
permit device 112 to communicate with network bus 120 (FIG. 1). 

In the FIG. 3 embodiment, platform- specific API 322 provides an 
interface that preferably permits network software 316 to communicate with 
vendor- specific platform 324. In the FIG. 3 embodiment, vendor-specific 

15 platform 324 may include basic operating system software for supporting 
low-level operations of device 112. 

The FIG. 3 embodiment of memory 216 typically corresponds to a full 
device (or FD, as discussed above in conjunction with FIG. 1) that preferably 
includes a complete set of network software 316 to permit optimal 

20 compatibility and functionality with network 110. Alternately, memory 216 
may correspond to an intermediate device (ID) which includes only a reduced 
set of software elements from network software 316. In contrast, a base 
device (BD) is preferably hosted on network 1 10 by a full device or an 
intermediate device, and therefore typically does not include network software 

25 316. A base device, however, preferably does include self-describing data 320 
and a device driver 318. 

A legacy device (LD) may be defined as a device that does not comply 
with the architectural specifications of network 110 and network software 
316. Legacy devices typically were designed and manufactured prior to the 

30 design and implementation of network 110 and network software 316. 

Therefore, a legacy device is preferably hosted on network 110 by a full device 
or an intermediate device, and typically does not include network software 
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316 or self-describing data 320. A digital base device, however, may include 
a device driver 318 for interfacing with network bus 120. Full devices, 
intermediate devices, base devices, and legacy devices are further discussed 
in the Home Audio/ Video Interoperability (HAVi) core specification (see pages 

5 3 through 22) that has been previously incorporated by reference. 

In accordance with the present invention, extended application 
program interface(s) (extended APIs) 326 preferably include application 
program interfaces that permit applications 312 or software elements from 
network software 316 to communicate (for example, by appropriate calls or 

10 messages) with a DCM 422 to thereby access and control extended 

capabilities of a corresponding device 1 12 on network 110. Techniques for 
discovering extended APIs 326 by applications 312 or network software 316 
are further discussed below in conjunction with FIGS. 6 through 11. 

15 Referring now to FIG. 4, a diagram for one embodiment of the network 

software 316 of FIG. 3 is shown, in accordance with the present invention. In 
the FIG. 4 embodiment, network software 316 preferably comprises a number 
of software elements, including a registry 412, an event manager 414, a 
device control module (DCM) manager 416, a stream manager 418, a 
20 resource manager 420, one or more device control modules (DCMs) 422 and 
one or more corresponding functional control modules (FCMs) 423, a 
messaging system 424, and a communication media manager (CMM) 426. 

In the FIG. 4 embodiment, software elements 412 through 426 are 
preferably configured to function in accordance with the Home Audio /Video 
25 Interoperability (HAVi) architecture which has previously been incorporated 
herein by reference. However, in alternate embodiments, network software 
316 may readily conform to any other appropriate and compatible 
interoperability architecture, and may also include various software elements 
that are different from, or in addition to, those elements 412 through 426 
30 that are presented in the FIG. 4 embodiment. 

In the FIG. 4 embodiment, registry 412 may preferably include a listing 
of software elements in network software 316. Registry 412 also preferably 
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may include relevant element information or attributes corresponding to the 
listed software elements. For example, elements 412 through 426 from 
network software 316 and corresponding element information may be listed 
in registry 412. Registry 412 therefore may serve as a directory service for 
5 applications 312 or software elements in network 110. Registry 412 may 
thus allow any application or software element to obtain a software element 
identifier (SEID) for identifying and locating another software element in 
network 110. In accordance with the present invention, registry 412 may 
also include a remote registry list that identifies all remote registries on 

10 network 110. 

In the FIG. 4 embodiment, event manager 414 preferably serves as a 
network-event notification service to notify various software elements (that 
have previously subscribed for notification) about the occurrence of a 
specified network event, such as a change in a software element or a change 

15 in network 1 10. DCM manager 416 is preferably responsible for installing 
and removing DCMs 422 on full devices or intermediate devices. Stream 
manager 418 is preferably responsible for managing real-time transfer of data 
and other information between various functional components of network 
110. 

20 In the FIG. 4 embodiment, resource manager 420 preferably facilitates 

the sharing of various resources and scheduling of various actions in network 
110. A device control module (DCM) 422 preferably includes a software 
element that is used to control a specific associated device on network 110. 
A given DCM 422 preferably includes one or more directly-corresponding 

25 functional control modules (FCMs) 423 that each control a specific functional 
component within the particular device 112 that corresponds to the FCM 
423. A full device or an intermediate device may preferably host a DCM 422 
to control a remote base device or a remote legacy device on network 110. In 
the FIG. 4 embodiment, messaging system 424 is preferably responsible for 

30 bi-directionally transferring various messages between the software elements 
of network software 316. Communication media manager (CMM) 426 
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coordinates and manages asynchronous and isochronous communications 
through device driver 318 onto network bus 120. 

Network software 316 preferably performs a number of significant and 
related operations whenever a particular device is removed from, or added to, 

5 network 110. When a device is added or removed from network 1 10, then 
network bus 120 preferably triggers a bus reset event which notifies all 
connected devices about the change in network 110. Following the bus reset 
event, all DCM managers 416 in network 110 preferably perform a 
negotiation procedure to determine which, if any, DCM manager 416 is the 

10 most appropriate host for controlling the newly-added device 112. Each DCM 
manager 416 in network 110 may therefore maintain a current list of all 
devices in network 110. Once a given DCM manager 416 is selected as host, 
that host DCM manager 416 responsively instantiates a new DCM 422 as an 
abstraction of the control interface of the newly-added device. Network 

15 software 316 preferably also updates relevant software element information in 
registry 412 whenever a device is removed from, or added to, network 110. 

Referring now to FIG. 5, a diagram for one embodiment of the FIG. 4 
registry 412 is shown, in accordance with the present invention. In the FIG. 
20 5 embodiment, registry 412 preferably includes an element registration 1 
(512(a)) through an element registration N (512(d)), and a DCM registration 
512(e). Each FIG. 5 element registration 512(a) through 512 (d) preferably 
corresponds to a local software element in local device 112. For example, any 
one of element registration 512(a) through 512 (d) may uniquely correspond 
25 to an associated software element from network software 316 (FIG. 4). 

In the FIG. 5 embodiment, each element registration 512(a) through 
512 (d) preferably includes a software element identifier (SEID) and a 
corresponding attribute list. Therefore, element registration 1 (512(a)) 
through element registration N (512 (d)) each preferably include a 
30 corresponding respective SEID 1 (514(a)) through SEID N (514(d)), and a 

associated respective attribute list 1 (516(a)) through attribute list N (516(d)). 
In alternate embodiments, registry 412 may readily be configured to include 

14 
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various components in addition to, or instead of, those shown in the FIG. 5 
embodiment. 

In the FIG. 5 embodiment, each SEID 1 (514(a)) through SEID N 
(514(d)) preferably includes a global unique identifier (GUID) and a software 
element local handle (SELH) that are used to uniquely identify a specific 
software element in network 110. Attribute list 1 (516(a)) through attribute 
list N (516(d)) preferably each include relevant information corresponding to 
the associated software element. For example, such relevant information 
may include, but is not limited to, an element manufacturer, an element 
model, a version level, and various other element features. 

In the FIG. 5 embodiment, registry 412 may advantageously be utilized 
during communications between various software elements (including 
applications 312) in network 110. In order to send a message to a target 
element in network 1 10, a source element (such as an application 312) 
preferably identifies the target element by using the corresponding SEID 514 
of that target element. In network 110, the source element preferably obtains 
the correct SEID 514 of the target element by accessing, from registry 412, 
the appropriate element registration 512 that uniquely corresponds to the 
target element. Once a source element locates an SEID 514 for a target 
element using any appropriate examination technique, then the source 
element may use the located SEID 514 to communicate with the 
corresponding target element via messaging system 424 (FIG. 4). For 
example, an application 312 may send a message via an extended API 326 to 
a DCM 422 of a VCR device 1 12 to thereby control an extended capability 
such as a half- speed fast forward function. 

In accordance with the present invention, DCM registration 512(e) 
preferably corresponds to a DCM 422 for a device 112 that includes 
capabilities that may be classified into an extended category of capabilities. 
In the FIG. 5 embodiment, DCM registration 512(e) preferably includes a 
DCM SEID 514(e) and a corresponding DCM attribute list 516(e). In alternate 
embodiments, DCM registration 512(e) may readily be configured to include 
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various components in addition to, or instead of those shown in the FIG. 5 
embodiment. 

In the FIG. 5 embodiment, DCM SEID 514(e) preferably includes a 
global unique identifier (GUID) and a software element local handle (SELH) 
that are used to uniquely identify a specific software element in network 110. 
DCM attribute list 516(e) preferably includes relevant information 
corresponding to the associated DCM 422. DCM attribute list 516(e) is 
further discussed below in conjunction with FIGS. 6 through 11. 

Referring now to FIG. 6, a diagram for one embodiment of the FIG. 5 
DCM attribute list 516 is shown, in accordance with the present invention. 
In the FIG. 6 embodiment, DCM attribute list 516 includes, but is not limited 
to, standard attributes 612 and extended API attribute(s) (EAAs) 614. 

Standard attributes 612 preferably include items that relate to basic 
characteristics or functions of the particular device that corresponds to DCM 
attribute list 516. For example, if the device is a VCR, then standard 
attributes 612 may include information identifying device as a VCR, as well 
as other relevant information such as manufacturer, model, and version level. 

In the FIG. 6 embodiment, EAA(s) 614 preferably include one or more 
special, non-standard attributes that correspond to extended capabilities or 
functionality of the corresponding device on network 110. The configuration 
and utilization of EAA(s) 614 are further discussed below in conjunction with 
FIGS. 7 through 11. 

Referring now to FIG. 7, a diagram for one embodiment of the FIG. 6 
extended API attribute(s) (EAAs) 614 is shown, in accordance with the 
present invention. In the FIG. 7 embodiment, EAA(s) 614 may comprise any 
number of separate and discrete EAA(s) 614. For example, FIG. 7 includes 
an EAA 1 (614(a) through an EAA N (614(c). In alternate embodiment, EAA(s) 
614 may likewise be readily configured using any other effective and 
appropriate manner. 
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Referring now to FIG. 8, a diagram for one embodiment of an exemplary 
FIG. 7 extended API attribute (EAA) 614 is shown, in accordance with the 
present invention. In one embodiment of the present invention, EAA 614 is 
preferably formatted as a tuple that encodes relevant information as a series 
5 of textual strings. In the FIG. 8 embodiment, EAA 614 preferably includes, 
but is not limited to, a method identifier (ID) 812 and a method signature 
814. 

In the FIG. 8 embodiment, EAA 614 may effectively be encoded using 
Interface Definition Language (IDL) which is designed to capture abstract 

10 interface APIs using a Common Object Request Broker Architecture (CORBA). 
Concepts and techniques relating to IDL and CORBA are discussed in 
"Client/ Server Programming with Java and CORBA," by Robert Orfali and 
Dan Harkey, Wiley Computer Publishing, 1998, which is hereby incorporated 
by reference. In alternate embodiments, any or all portions of EAA 614 may 

15 readily be encoded using any other appropriate formats or languages. 

In the FIG. 8 embodiment, method ID 812 preferably includes an 
identifier that uniquely corresponds to a particular extended API 326. 
Similarly, method signature 814 preferably includes encoded signature 
information corresponding to the particular extended API 326. One 

20 configuration for method signature 814 is further discussed below in 

conjunction with FIG. 9. In alternate embodiments, EAA 614 may readily 
comprise various other information that is different from, or in addition to the 
information discussed above in conjunction with the FIG. 8 embodiment. 

25 Referring now to FIG. 9, a diagram for one embodiment of a FIG. 7 

exemplary method signature 814 is shown, in accordance with the present 
invention. In the FIG. 9 embodiment, method signature 814 preferably 
comprises, but is not limited to, a method string 912 and a set of parameters 
that preferable include a parameter name 914 and a parameter type 916. 

30 However, in alternate embodiments, method signature 814 may readily be 
configured to include any other appropriate information. 
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In the FIG. 9 embodiment, method string 912 preferably includes a 
textual string describing a method corresponding to a given extended API 
326. For example, in the case of a VCR with an extended API 326 for a half- 
speed fast forward function, the method string 912 may include the string 
5 "half-speed fast forward". In the FIG. 9 embodiment, parameter name 914 
preferably includes a textual string describing a given parameter for the 
corresponding extended API 326. For example, in the case of a VCR with a 
half- speed fast forward function, the parameter name 914 may include the 
string "speed". In the FIG. 9 embodiment, parameter type 916 preferably 

10 includes a textual string describing a specific type for the parameter 

identified by parameter name 914. For example, in the case of a VCR with a 
half-speed fast forward function, the parameter type 916 may include the 
string "integer". In alternate embodiments, method signature 814 may 
readily be configured to include various other information in addition to, or 

15 instead of the information discussed above in conjunction with the FIG. 9 
embodiment. 

Referring now to FIG. 10, a flowchart of method steps for registering a 
DCM 422 of an added device is shown, in accordance with one embodiment 
20 of the present invention. In the FIG. 10 embodiment, in step 1010, network 
software 216 monitors network 1 10 to determine whether a system user has 
recently connected an added device to network 110. 

If a system user has connected an added device to network 110, then, 
in step 1012, network 1 10 preferably generates a bus reset event to notify 
25 interested devices 112 about the presence of the added device. In step 1014, 
DCM manager 416 of network software 316 preferably performs a device 
discovery process for the added device. 

In the FIG. 10 embodiment, DCM manager 416 preferably performs the 
foregoing device discovery process by querying various relevant configuration 
30 information stored in* self-describing data (SDD) 320 (FIG. 3). In accordance 
with the present invention, DCM manager 416 may also concurrently 
discover relevant extended capability information relating to the added device 
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during Hie foregoing device discovery process. For example, SDD 320 may 
include various types of extended capability information for creating one or 
more extended API attributes (EAAs) 614. 

In step 1016, DCM manager 416 preferably locally instantiates a new 
5 DCM 422 for controlling the added device on network 110, as discussed 
above in conjunction with FIG. 4. Finally, in step 1018, DCM manager 416 
creates a DCM registration 512(e) (FIG. 5) to register the new DCM 422 into 
local registry 412. In accordance with the present invention, the DCM 
registration 512(e) created in step 1018 may include one or more extended 
10 API attribute(s) (EAAs) 614 corresponding to various extended capabilities of 
the added device that was connected to network 1 10 in foregoing step 1010. 

Referring now to FIG. 1 1, a flowchart of method steps for discovering 
extended APIs 326 is shown, in accordance with one embodiment of the 

15 present invention. In the FIG. 1 1 embodiment, in step 1 1 10, a local software 
module (such as application 312 or any other software element in network 
110) determines whether an extended API 326 is required to access a given 
extended capability of a target device that is represented by a locally-hosted 
DCM 422. For example, in one embodiment, an application 312 may wish to 

20 communicate with given DCM 422 to thereby control an extended half-speed 
fast forward function of a VCR on network 110. 

If an extended API 326 is required, then, in step 1112, the local 
software module creates and propagates a query to local registry 412 to locate 
the DCM registration 512(e) corresponding to the target device on network 

25 1 10. In some embodiments, registry 412 may broadcast the query to other 
remote registries 412 across network 110 in the event that the initial query to 
local registry 412 is unsuccessful. 

In step 1114, registry 412 determines whether the foregoing query of 
step 11 12 has been successful in locating the desired DCM registration 

30 512(e). If the query is not successful, then, in step 1 126, registry 412 returns 
a failure message to the local software module that originated the query. 
However, if the query of step 1112 successfully locates the appropriate DCM 
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registration 512(e), then, in step 1 1 16, registry 412 returns the 
corresponding DCM SEID 514(e) to the local software module that originated 
the query. 

In step 1118, the local software module of step 1110 may then access 
the entire DCM attribute list 516(e) corresponding to the target device with 
the desired extended capability. Next, in step 1120, the local software 
module of step 1110 may advantageously scan the DCM attribute list 516(e) 
to locate the desired extended API attribute (EAA) 614, in accordance with the 
present invention. 

In step 1 122, the local software module of step 1110 may then access 
and parse the extended API attribute 614 to identify the corresponding 
extended API 326. Finally, in step 1 124, the local software module of step 
1110 may responsively build a request call using information from the 
extended API attribute 326, and may then send the request call to DCM 422 
through the identified extended API 326 using any appropriate and 
compatible messaging protocol. For example, in one embodiment, the 
request call of step 1 124 may include information such as the DCM SEID 
514(e), method ID 812, parameter name 914, and parameter type 916. 

The foregoing discussion of the FIG. 1 1 embodiment is presented in the 
context of a single local software module discovering a single extended API 
326, however the present invention may readily be utilized to allow any 
number of software modules across network 1 10 to discover and utilize any 
number of local or remote extended APIs 326 on various devices across 
network 110. 

The invention has been explained above with reference to a preferred 
embodiment. Other embodiments will be apparent to those skilled in the art 
in light of this disclosure. For example, the present invention may readily be 
implemented using configurations and techniques other than those described 
in the preferred embodiment above. Additionally, the present invention may 
effectively be used in conjunction with systems other than the one described 
above as the preferred embodiment. Therefore, these and other variations 
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WHAT IS CLAIMED IS: 

1. A system for discovering an extended capability of a device (1 12) in an 
electronic network (110), comprising: 
5 a registry (412) configured to include an extended attribute (614) 

corresponding to said extended capability; and 
a software module (312) configured to utilize said extended attribute 
(614) for accessing said extended capability of said device (1 12). 

10 2. The system of claim 1 wherein said software module (312) is a device 
application that communicates with said device (112) on said electronic 
network (110). 

3. The system of claim 1 wherein said registry (412) forms part of network 
15 software (316) for said electronic network (1 10). 

4. The system of claim 3 wherein said network software (316) is 
configured to comply with a home audio-video interoperability specification. 

20 5. The system of claim 1 wherein said electronic network (110) is 

connected through a network bus (120) configured using an IEEE 1394 
interconnectivity standard. 

6. The system of claim 1 wherein a manager element encodes said 
25 extended attribute (614) in an attribute list (516(e)) within a module 

registration (512(e)) to thereby include extended API information in said 
extended attribute (614), and wherein said software module (312) 
responsively utilizes said extended API information to discover and use an 
extended API (326) for controlling said extended capability through a device 
30 control module (422). 
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7. The system of claim 1 wherein a DCM manager (416) performs a device 
discovery procedure following a connection of said device (112) to said 
electronic network (110), said DCM manager (416) examining self-describing 

5 data (320) in said device (112) to learn about said extended capabilities 
during said device discovery procedure. 

8. The system of claim 7 wherein said DCM manager (416) instantiates a 
device control module (422) to control said device (112) on said electronic 

10 network (110). 

9. The system of claim 8 wherein said DCM manager (416) creates a DCM 
registration (512(e)) in said registry (412), said DCM registration (512(e)) 
including a DCM software element registration (514(e)) and a DCM attribute 

15 list (516(e)). 

10. The system of claim 9 wherein said DCM attribute list (516(e)) includes 
standard attributes (612) and said extended attribute (614). 

20 11. The system of claim 10 wherein said extended attribute (614) 

comprises extended API information that is obtained by said DCM manager 
(416) during said device discovery procedure, said extended API information 
being encoded as a textual string to include a method ID (812) corresponding 
to an extended API (326), and a method signature (814) also corresponding to 

25 said extended API (326). 

12. The system of claim 11 wherein said method signature (814) comprises 
a method string (912) corresponding to said extended API (326), and set of 
parameters also corresponding to said extended API (326), said set of 
30 parameters including a parameter name (914) and a parameter type (916). 
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13. The system of claim 1 wherein said software module (312) utilizes an 
extended API (326) to communicate with said extended capability of said 
device (112). 

14. The system of claim 13 wherein said software module (312) sends a 
query to said registry (412) to locate a DCM registration (512(e)) 
corresponding to a device control module (422) that controls said device 
(112). 

15. The system of claim 14 wherein said registry (412) returns a DCM 
software element identifier (514(e)) to said software module (312) when said 
query is successful. 

16. The system of claim 14 wherein said registry (412) returns a failure 
message to said software module (312) when said query is unsuccessful. 

17. The system of claim 14 wherein said software module (312) accesses an 
attribute list (516(e)) within said DCM registration (512(e)) in said registry 
(412). 

18. The system of claim 17 wherein said software module (312) scans said 
attribute list (516(e)) to locate said extended attribute (614). 

19. The system of claim 18 wherein said software module (312) accesses 
and parses said extended attribute (614) to extract extended API information. 

20. The system of claim 19 wherein said software module (312) utilizes said 
extended API information to construct and send a request call via said 
extended API (326) to said device control module (422), to thereby control 
said extended capability of said device (112). 
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21. A method for discovering an extended capability of a device (1 12) in an 
electronic network (1 10), comprising the steps of: 

storing into a registry (412) an extended attribute (614) corresponding 
to said extended capability; and 
5 accessing said extended capability with a software module (312) by 

utilizing said extended attribute (614). 

22. The method of claim 21 wherein said software module (312) is a device 
application that communicates with said device (112) on said electronic 

10 network (110). 

23. The method of claim 21 wherein said registry (412) forms part of 
network software (316) for said electronic network (110). 

15 24. The method of claim 23 wherein said network software (316) is 

configured to comply with a home audio-video interoperability specification. 

25. The method of claim 21 wherein said electronic network (110) is 
connected through a network bus (120) configured using an IEEE 1394 

20 interconnectivity standard. 

26. The method of claim 21 wherein a manager element encodes said 
extended attribute (614) in an attribute list (516(e)) within a module 
registration (512(e)) to thereby include extended API information in said 

25 extended attribute (614), and wherein said software module (312) 

responsively utilizes said extended API information to discover and use an 
extended API (326) for controlling said extended capability through a device 
control module (422). 

30 
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27. The method of claim 21 wherein a DCM manager (416) performs a 
device discovery procedure following a connection of said device (112) to said 
electronic network (110), said DCM manager (416) examining self-describing 
data (320) in said device (1 12) to learn about said extended capabilities 

5 during said device discovery procedure. 

28. The method of claim 27 wherein said DCM manager (416) instantiates 
a device control module (422) to control said device (112) on said electronic 
network (110). 

10 

29. The method of claim 28 wherein said DCM manager (416) creates a 
DCM registration (512(e)) in said registry (412), said DCM registration (512(e)) 
including a DCM software element registration (514(e)) and a DCM attribute 
list (516(e)). 

15 

30. The method of claim 29 wherein said DCM attribute list (516(e)) 
includes standard attributes (612) and said extended attribute (614). 

31. The method of claim 30 wherein said extended attribute (614) 

20 comprises extended API information that is obtained by said DCM manager 
(416) during said device discovery procedure, said extended API information 
being encoded as a textual string to include a method ID (812) corresponding 
to an extended API (326), and a method signature (814) also corresponding to 
said extended API (326). 

25 

32. The method of claim 31 wherein said method signature (814) comprises 
a method string (912) corresponding to said extended API (326), and set of 
parameters also corresponding to said extended API (326), said set of 
parameters including a parameter name (914) and a parameter type (916). 
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33. The method of claim 21 wherein said software module (312) utilizes an 
extended API (326) to communicate with said extended capability of said 
device (112). 

5 34. The method of claim 33 wherein said software module (312) sends a 
query to said registry (412) to locate a DCM registration (512(e)) 
corresponding to a device control module (422) that controls said device 
(112). 

10 35. The method of claim 34 wherein said registry (412) returns a DCM 
software element identifier (514(e)) to said software module (312) when said 
query is successful. 

36. The method of claim 34 wherein said registry (412) returns a failure 
15 message to said software module (312) when said query is unsuccessful. 

37. The method of claim 34 wherein said software module (312) accesses 
an attribute list (516(e)) within said DCM registration (512(e)) in said registry 
(412). 

20 

38. The method of claim 37 wherein said software module (312) scans said 
attribute list (516(e)) to locate said extended attribute (614). 

39. The method of claim 38 wherein said software module (312) accesses 
25 and parses said extended attribute (614) to extract extended API information. 

40. The method of claim 39 wherein said software module (312) utilizes 
said extended API information to construct and send a request call via said 
extended API (326) to said device control module (422), to thereby control 

30 said extended capability of said device (112). 
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41. A system for discovering an extended capability of a device (1 12) in an 
electronic network (110), comprising: 

means for storing an extended attribute (614) corresponding to said 

extended capability; and 
means for accessing said extended capability by utilizing said extended 

attribute (614). 

42. A computer-readable medium comprising program instructions for 
discovering an extended capability of a device (1 12) by performing the steps 
of: 

storing into a registry (412) an extended attribute (614) corresponding 

to said extended capability; and 
accessing said extended capability with a software module (312) by 

utilizing said extended attribute (614). 
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